Agent skills install from the npm packages the project already has - #219

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Fixture projects in the layouts npm and pnpm produce, a workspace with
two members pinning different versions, and a Yarn PnP fixture that
patches Node's resolver and the filesystem module the way .pnp.cjs
does — so the tests fail if the sync ever builds a node_modules path
itself or reads through an API the PnP layer does not patch.

Covers every state a copy can be in (in sync, stale, never synced,
orphaned), pruning on package removal, leaving skills from other
packages alone, exit 0 whenever there is nothing to do, and each of the
check's off switches.

The fixtures clear NODE_PATH first: vitest points it at this
repository's pnpm store, which would otherwise make every fixture
project look like it had two allowlisted packages installed.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

The staleness notice is not TTY-gated, which the update-notification
section would otherwise imply is the rule for advisory stderr lines, so
its own section says why and lists every way to silence it.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

`prisma --config <path> skills list` invokes the command that fixes
stale skills, so the check must recognise the group even when shared
flags come first. Also trims sync's help to the two examples the style
guide asks for.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

A `packages/**` workspace made member enumeration walk the whole
working tree — dist, coverage, .git, every source directory — and the
resolver was then pointed at each one, four package names at a time.
The staleness check runs that on every command, so an ordinary
workspace pattern cost roughly a second per invocation instead of the
milliseconds the design budgets.

The walk now stops at a directory holding a package.json, because that
directory is the member and everything below it is the package's own
contents, and it never enters a dot-directory. Only directories with a
package.json are returned, so `**` answers with packages rather than
with directories.

The new test counts directory reads rather than timing them: on a
workspace with two built members it reads `packages` and
`packages/group` and nothing else.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

`skills sync` printed `check: enabled` in a project whose
prisma.config.ts sets `skills: { check: false }`, contradicting
`skills list` and the check itself. It now needs the same config
section and combines it with the persisted opt-out the same way.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

The Agent Skills spec defines no custom top-level frontmatter keys;
extensions live under `metadata`, a map of strings. Slices 1 and 4 are
stamping `metadata.library` and `metadata.library_version`, so the
reader follows them there and nowhere else. No fallback to the old
top-level spelling: nothing has shipped one, and accepting both would
let a skill claim a stamp the spec has no place for.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Operator decision: the published binary is `prisma`, so CLI_NAME — the
one place the user-facing name lives — now says `prisma`, and every
command string, notice, error next step, help line and sample output
follows it. `prisma-cli` survives only where it names something that
really is still called that: the `@prisma/cli` package's own bin (its
README and the update check's entrypoint detection), the update-check
cache directory, the repository URL, the sign-in campaign tag, and the
legacy error copy the service group rewrites.

That rewriting is why one behavioural change came with the rename:
`fromLegacyCliError` turned a legacy `nextSteps` line into a
run-command action only when it began `prisma-cli `, and dropped every
other line. Legacy builders written with the new spelling would have
lost their next steps, so the mapper now recognises both spellings and
renames `<name> app ` to `<name> service ` either way.

The feedback client's user-agent follows CLI_NAME too, so it now
reports `prisma/<version>`; it identifies this binary, and this binary
is called prisma.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

`/docs/orm/tools/prisma-cli` is the path that 308-redirects to the ORM
CLI reference, which is the whole reason the comment cites it. The
sweep matched it because the path was followed by a space, and
output-conventions.md kept the right spelling, so the two disagreed.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

The mapper's current-spelling branch does have a producer —
`computeConfigErrorToCliError` writes `prisma service <command>` into
nextSteps, and `resolveComputeManagementContext` maps it — so removing
the branch fails two tests in service-compute-config. What it lacked
was a test that says so directly: those two fail for reasons that read
as compute-config behaviour.

These drive `renameAppCopy` and `fromLegacyCliError` with one spelling
each, and pin the asymmetry that makes this worth covering — a command
line the mapper does not recognise is dropped from nextActions rather
than passed through, so an unrecognised spelling costs the user their
next step with nothing to show for it.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Round-4 review fixes (S2-R3-1, S2-R3-2), committed at session halt;
suites not re-run. Includes drive project artifacts up to this point.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

The branch's only cli-engine change was two doc-comment lines renamed in a prisma-cli -> prisma sweep. That trips the engine-version check because 0.2.0 is already published, and publishing the engine for comments is not worth it. Restore the file to origin/main byte-for-byte.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Both failures were in test fixtures, not production code — the skills library joins every path with path.join, which is correct on Windows.

skills-pnp: the fake PnP layer remapped virtual paths with a startsWith check against a forward-slash prefix, but on Windows path.join hands it backslash paths, so the remap missed and sync found no packages. The fixture now compares in forward-slash form.

skills-workspace-scan: the recorded readdir paths carry native separators, so the expected relative paths did not match on Windows. The assertion now normalizes separators before comparing; the set of directories it pins is unchanged.
Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

…eout flake

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

skills.agents in prisma.config.ts names which agent harnesses get skill copies; the default is every known agent (claude, cursor, agents, devin — windsurf is gone, its product renamed to Devin Desktop which reads .devin/skills). findProjectRoot is deleted: sync, list, the staleness notice, the post-login tip and the opt-out file all read from the directory the command runs in. The notice stays cheap: it reads the full agent set first and evaluates the config at most once, only when that already looks stale and only when a config file exists.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

The hand-written pnpm-workspace.yaml line parser and glob matcher go. PnpmTool and YarnTool read the declared globs from plain files (pnpm-workspace.yaml, package.json workspaces in both forms) and expand them with node_modules excluded, which covers npm, pnpm, bun and Yarn PnP alike and keeps the trust boundary: membership comes only from what the user declared, never from scanning installed packages.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

A fresh project gets a config with skills.agents spelled out; an existing prisma.config.ts is never edited — init reports the exact snippet to add instead. --skills takes the comma-separated agent list that both the scaffold and this run's sync use, or 'none' to skip the skills steps; --no-skills is gone.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

The temp project gets a node_modules/prisma symlink to the built package, so the scaffold's prisma/config import resolves exactly as in a user install, and the file init wrote is evaluated by the same loadConfig every command uses, asserting zero diagnostics. The rerun test removes the config first: the built binary cannot currently evaluate any prisma.config.ts in this repository's development layout (a defect that predates this work, reproduced at commit 7532706 with a dependency-free config; the c12 import inside the engine resolves through the pnpm symlink and misses its store siblings). The config-exists rerun stays covered in the unit suite.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

output-conventions and command-principles describe the agents map, the default set, init's scaffold and the never-edit rule; the prisma package declares @manypkg/tools so its bundle keeps the dependency external like its other runtime deps.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

…file text

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

…figs

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

…project's config

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

…requires

packages/prisma pinned @prisma/orm-toolchain 8.0.0-rc.4 and
@prisma/composer-cli 0.11.0 while bundling @prisma/cli source that
requires rc.5 / 0.12.0. A command definition imported from rc.4 comes
back undefined and the engine crashes with 'Cannot read properties of
undefined (reading needs)' on every invocation, --version included.
The skew is pre-existing on main. Align the pins with packages/cli.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

When the c12 specifier resolves through a pnpm symlink that is never
realpath'd (the dev workspace layout, and pnpm installs with
hoist=false), c12's own 'import "pathe"' walks up from the symlink
path, where its store siblings are unreachable, and every config
evaluation fails with CLI.CONFIG_UNREADABLE: Cannot find package
'pathe'. Import c12 through the realpath of its resolved URL instead.
A resolution failure still throws inside evaluateConfigFile, so it
still surfaces as the unreadable-config diagnostic.

The import-purity conformance check now excuses c12 from the
reverse (unimported-dependency) half: import.meta.resolve is not an
import, which is the exact case allowedUnimported exists for.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

The rerun no longer deletes prisma.config.ts before invoking the
built binary: with c12 imported through its realpath the binary can
evaluate the config in this repository's layout, so the test now
asserts the honest behavior — a second init with the config present
reports the config step as exists and exits 0.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

An engine change forces a version bump, and the published families peer-pin the engine exactly, so shipping it means a coordinated family release. The defect only affects this repo's dev layout and pnpm hoist=false installs — npm and default pnpm installs evaluate configs fine — so it waits for the next engine train. The verified one-line fix (import c12 through its realpath) is recorded in the e2e comment and the ledger.

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>